FunnelFlux Pro has a number of resources that are necessary precursors to building a funnel and running a fully-featured campaign.
They are:
- Traffic sources
- Offer sources
- Offers
- Landers
- A custom domain (not really a resource, but necessary)
Below is a breakdown of the configuration for these items and how they impact tracking processes.
Traffic Sources
A traffic source defines the source of incoming visitors and this must be selected when generating campaign URLs.
The traffic source config has two primary components:
- The URL tracking fields
- Conversion tracking
URL Tracking Field config
See image below:
FunnelFlux allows for 20 custom tracking fields, which must each have a name (an alias) and an optional placeholder value. The numbers on the left side represent column numbers in the database. Thus this configuration is creating aliases for mapping name -> column ID.
The tracking field config is used when generating redirect/direct links -- these fields determine the traffic source-specific query string data appended to the URL.
We have two reserved fields that cannot be removed, but can be aliased -- campaign and external.
These are reserved for campaign ID values (or campaign name) and click tracking IDs, respectively.
The placeholders should all be the tokens/macros that the traffic source will parse (since these are in URLs expected to be used at the traffic source), and the FunnelFlux token is the token format usable in lander/offer URLs to pass traffic source data onward.
Useful notes
- Traffic sources do not need to be ad platforms -- you could make a traffic source for emails, using email merge tags as tokens. You could also make traffic sources for specific affiliates, with manually created fields and let the user pass static data. When doing so, it is a best practice to put the placeholder as REPLACE, to reduce human error when using links.
- If a tracking field has its placeholder left blank, we will omit it from the URL generated, but the field will still be captured if the URL data exists.
- In some cases it may make sense to unlock our reserved fields and rename them, where a campaign or click ID is automatically appended to URLs -- such as with Facebook appending "FBCLID" automatically. In our template, the external field is rename to FBCLID, and given a blank placeholder. Our system will thus NOT add FBCLID= to the URLs generated, but will capture incoming FBCLID query string parameter values and store them as external click IDs.
- Users can rename fields at any time and this can lead to the data logging to a numbered column abruptly changing at some point in time, so care should be taken to not significantly alter the data coming into each column number post-setup. Rather, it would be better to archive that numbered row and craete a new field, or use a new traffic source.
- Archived tracking fields are hidden from view and reporting dropdowns, but still appear in data. Creating a new row with the same name as an archived field will unarchive that field rather than creating a duplicate field, as the archived one will still capture and store data if URLs use it.
- When renaming fields, a previousName value is stored for mapping old link URL data to renamed values.
Conversion Tracking config
Here, users can set the method for passing conversion data back to the traffic source.
Postback URLs are simple GET requests to the source, passing whatever data is required and our {external} token for the click ID available.
HTML allows for JS or image pixels. For this to work, users must track a conversion with our JavaScript tracking, which will piggyback the HTML code through to the page if set.
Custom Scenarios are custom integrations we have created for various traffic sources, which typically involve an API.
Users will need to consult our help documentation for setup details. These should be leveraged if available, as they will give much more reliable tracking. They are all server-to-server based so work when conversions are passed to FunnelFlux with postback URLs, but also if conversions are triggered with JS.
Offer Sources
These define the source of offers, which are usually affiliate networks. Though, a user could very well create sources like "My Products" or a website name.
These serve three purposes:
- Templating data passing, as when an offer uses this source, it inherits data passing config
- Templating postback URLs, to make it easy for users to copy/paste URLs to networks
- As a general category for reporting
Note: we intend to update our data passing paradigm in the near future. Right now, offer source config is inherited one-way at the time it is selected in the offer config. If the user updates the offer source, no changes are made to offers. In the future, we will create strict inheritance where offers first inherit data passing config from the source (and some other config), then at the offer level additional fields can be set as well as overrides.
Data passing
Here users can use a form-based approach to build the query string appended to the base page URL under general settings.
This approach reduces human error and allows us to better template data passing.
As a best practice, the base page URL should contain all static URL data that will never change. For affiliate URLs, this often means including some affiliate/offer ID.
All dynamic data should be configured via the data passing section, ideally.
Useful Notes
- Some field names are restricted like vid, n, c, ts, etc. that are used for reserved parameters passed by FunnelFlux or our Javascript
- To pass URL data, you can pick that option then enter the query string key name only. On save the item will collapse to
{data-url_key_name}-- we intend to improve this later. - Note that data passed in tracking links is accessed via this token, as is query string data passed into our URL buffer. That is, any URL query string data passed into a redirect or action link that is NOT a defined tracking field will still be stored in session data and can be accessed with
{data-url_key_name}. It will however not be available in reporting. - For passing composite or other data, select custom string. Here you can use tokens as usual so can do e.g.
{funnel-id}-{campaign}-{trafficsource-id}. If passing complex data like a URL string, it does not need to be encoded as our system will URL encode it automatically on save.
Conversion Tracking
This section is rather self-explanatory.
For templating the postback URL, enter the revenue/optional transaction ID tokens that the offer source's platform will parse and replace.
For hit ID, check the field you are passing our {hit} value to in data passing. If it is "aff_sub5" for example, then on the conversion tracking page, you should enter the offer source's corresponding token that would represent the stored aff_sub5 value, e.g. {aff_sub5}
Useful Notes
- Conversions passed to FunnelFlux with identical hit ID and TxID values will currently replace the existing conversion but not cause duplication. Right now this updates the conversion timestamp. We intend to replace this functionality to NOT update the original timestamp, so the new event, if a duplicate, is effectively ignored.
- Currently, conversion tracking is not deduplicated with respect to firing events to the traffic source. So even if FunnelFlux deduplicates the conversion internally, an event is still sent to the traffic source. We also intend to update this behaviour to not send duplicate events.
- Thus, if users want to fire multiple legitimate conversions, they should always specify unique transaction ID values via the "tx" parameter in our postback URL/JS.
Offers
Offers should pick an offer source to first inherit important config, saving time and reducing human error.
The offer then has a base URL, which should include all static data with all dynamic data passed via the data passing section.
When FunnelFlux redirects to an offer, it will redirect to the base URL + data passing config = final offer URL.
Offer categories are purely for grouping in reporting and have no functional impact.
Page Action Links
These are the action (CTA) URLs to be used on pages. They are generic and of the format:
https://DOMAIN/action/number
In FunnelFlux, clickthrough URLs (action links) on pages do not specify a destination. They reference an "action" to execute. At the time of click, FunnelFlux will process the funnel config for the current user, and based on their current known node position, execute action X from that node.
In this way, FunnelFlux does not forecast what the next destination for a user will be, and its thus not possible to create a link on a page that creates a clickthrough/action but also forces a certain node to be redirected to.
One could of course use a condition node and route based on some URL data passed into the action URL, but this is a separate functionality -- the action from the lander would still be naturally going to the next expected node (a condition in this case).
Note action links are generic and do not need to be specific to the page, funnel or source. Within the funnel builder these actions can also be retrieved with default parameters added. That will be discussed in the funnel technical document.
Integration product IDs
This is a section in beta - it is specifically for webhook integrations we plan to build, where they will pass product IDs and a visitor ID. If an offer has a product IDs set, we will be able to cross-reference to determine that X product ID must be Y offer --> that is the offer that converted. Currently of limited use.
Landers
Much like offers, a lander is just a page.
The key differences other than icon/name is that a lander has no "source" from which it inherits configuration
Landers should be used for any page that is not going to directly create revenue from a user action on that page, or stemming from it.
For example, a checkout page would likely be an offer page -- but the previous product sales page would be a lander, as the checkout page is the place where the user ultimately converts.
Any page that is a terminus, where a visitor is redirected to some third-party e.g. an affiliate network, will surely be an offer, not a lander.
Note that while landers don't convert, in reporting they still inherit revenue and conversions created by users later in their journey.